A NetBIOS name is a unique 16-byte address used to identify a NetBIOS resource on the network. This name is either a unique (exclusive) or group (nonexclusive) name. Unique names are typically used to send network communication to a specific process on a computer. Group names are used to send information to multiple computers at one time. An example of a process that uses a NetBIOS name is the File and Printer Sharing for Microsoft Networks service on a computer running Windows 2000. When your computer starts up, this service registers a unique NetBIOS name based on the name of your computer. The exact name used by the service is the 15-character computer name plus a 16th character of 0x20. If the computer name is not 15 characters long, it is padded with spaces up to 15 characters.
NetBIOS name resolution is the process of mapping a computer's NetBIOS name to an IP address. A computer's NetBIOS name must be resolved to an IP address before the IP address can be resolved to a hardware address. Microsoft TCP/IP uses several methods to resolve NetBIOS names; however, the exact mechanism by which NetBIOS names are resolved to IP addresses depends on the NetBIOS node type that is configured for the node. Request for Comments (RFC) 1001, "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods," defines the NetBIOS node types, as listed in Table 1.
Table 1 NetBIOS Node Types
| Node Type | Description |
|---|---|
| B-node (broadcast) | B-node uses broadcast NetBIOS name queries for name registration and resolution. B-node has two major problems: (1) Broadcasts disturb every node on the network. (2) Routers typically do not forward broadcasts, so only NetBIOS names on the local network can be resolved. |
| P-node (peer-peer) | P-node uses a NetBIOS name server, such as a WINS server, to resolve NetBIOS names. P-node does not use broadcasts; instead, it queries the name server directly. |
| M-node (mixed) | M-node is a combination of B-node and P-node. By default, an M-node functions as a B-node. If an M-node is unable to resolve a name by broadcast, it queries a NetBIOS name server using P-node. |
| H-node (hybrid) | H-node is a combination of P-node and B-node. By default, an H-node functions as a P-node. If an H-node is unable to resolve a name through the NetBIOS name server, it uses a broadcast to resolve the name. |
WINS Overview
WINS eliminates the need for broadcasts to resolve computer names to IP addresses and provides a dynamic database that maintains mappings of computer names to IP addresses. WINS is an enhanced NetBIOS name server (NBNS) designed by Microsoft to eliminate broadcast traffic associated with the B-node implementation of NetBT. It is used to register NetBIOS computer names and resolve them to IP addresses for both local and remote hosts.
There are several advantages of using WINS. The primary advantage is that client requests for computer name resolution are sent directly to a WINS server. If the WINS server can resolve the name, it sends the IP address directly to the client. As a result, a broadcast is not needed and network traffic is reduced. However, if the WINS server is unavailable, the WINS client can still use a broadcast in an attempt to resolve the name. Another advantage of using WINS is that the WINS database is updated dynamically, so it is always current. This eliminates the need for an LMHOSTS file. In addition, WINS provides network and interdomain browsing capabilities.
Before two NetBIOS-based hosts can communicate, the destination NetBIOS name must be resolved to an IP address. This is necessary because TCP/IP requires an IP address rather than a NetBIOS computer name to communicate. Resolution uses the following process:
Windows for Workgroups' native networking architecture provides users in a small local area network with limited file- and printer-sharing capabilities. Users can connect to other Windows for Workgroups PCs, and use other systems' shared resources.
This functionality is a result of the combined functionality offered by a collection of various networking components. The following diagram illustrates the interaction between these components. We'll discuss these components in more detail in just a moment.
+-------------------------------------------------------+ | Network Driver | | +---------------------------+ | | Redirector and Server | NetBIOS Applications | +---------------------------+ | | Server Message BLocks | | +---------------------------+---------------------------+ | NetBIOS APIs | +-------------------------------------------------------+ | NetBIOS-over-TCP/IP (NBT) | +-------------------------------------------------------+ | Transport Driver Interface (TDI) | +-------------------------------------------------------+ | TCP/IP Suite for Windows TCP/IP | +-------------------------------------------------------+
At the top of the heap rests the network driver. Just as Windows has video "drivers" that tell the operating environment about specific features that your video adapter offers, it also has drivers that inform it about the network operating systems in use on the PC. These drivers provide a browsable interface to the network, generally through File Manager and Print Manager.
Windows for Workgroups' native network driver is an adaptation of the LAN Manager Windows client driver from Windows 3.1. It provides a browsable interface to servers based on Microsoft's LAN Manager. This includes Windows for Workgrous, Windows NT, Windows 95, Digital PathWorks, SAMBA, and several other products.
The network driver itself only provides an interface to the network resources. It does not provide any protocol or service functions.
Note: The network driver is not to be confused with the network adapter driver. The network adapter driver is generally DOS-based, and is part of the user's ODI or NDIS installation, providing an interface between the low-level protocols and the network adapter itself. The network driver, on the other hand, provides an interface between Windows and the network operating system.
The client redirector is what handles the presentation of resources on the network. This module handles user account security, resource availability, the actual "connection" to a remote server's resource, and other network operating system-specific functions. Essentially, once two computers are able to communicate with each other, the redirector provides the local operating system with the ability to access the remote system.
For example, File Manager doesn't understand network concepts explicitly, but instead relies on the redirector to handle requests for it. If you connect to a remote server and list the files in one of its directories, these requests are passed to the Windows kernel which checks to see if the resource is local or remote. If it is remote, it passes the request to the redirector, which passes it to the remote system. That system processes the request, and returns some sort of answer. The redirector then passes the data back to the kernel for presentation to the application that requested it.
Windows for Workgroups also provides a server component that listens for requests from remote systems. If you have enabled file sharing on your PC and another user connects to your system, then his redirector is talking to your server. The server is, in essence, the opposite of the redirector. However, the server also relies on the redirector to provide the interface to the network for it. When the server wishes to advertise a resource, it publishes the information with the redirector, which then sends the information out onto the wire.
When two Windows for Workgroups nodes communicate, they must use a common set of commands. They can't just pass arbitrary strings of data around the network. With Windows for Workgroups and other derivatives of LAN Managers, a "dictionary" of network-I/O commands is provided by the X/Open-standard Server Message Blocks (SMBs). SMBs provide a well-defined method for servers and nodes (called consumers in the SMB definition) to communicate with each other.
The SMB specification is comprised of a list of network commands. For example, if a user wants to open a file that resides on a server, then the SMB command "SMBopen" is passed between the two systems. This occurs at the redirector level. The client PC's redirector sends the SMBopen command to the server PC's redirector module, which passes the request up to the server, which then interprets the request, and hopefully sends the file back to the client PC.
SMB commands exist for a wide range of functions, and provide a quick and cost-effective way to do the most common network functions. Commands exist for things like login security, printing, and working directly with files and directories. In other words, the SMB protocol is the heart of the network, providing a common language for all the clients and servers to use.
Note that by implementing SMBs on different systems, the client is able to communicate with them. If those systems were not running SMB-based servers, then the redirector would not be able to communicate with them. This is also very similar to the NFS model. As long as you've got an NFS server component on a system, then NFS clients can connect to it and exchange data.
Just as there are file- and print-sharing mechanisms, there are also generic network applications that communcicate between multiple systems. In the TCP/IP world, these applications are FTP, the World Wide Web, Internet Relay Chat (IRC), and many others. In the Windows for Workgroups world, these applications are generally NetBIOS-based, and not TCP/IP-based.
Two of the NetBIOS applications that come with Windows for Workgroups include the Chat and ClipBook applets. They allow users to connect with other NetBIOS systems and exchange data. These programs do NOT use SMBs since they are not tied in to the redirector. However, they are similar to the redirector/server model since they are node-to-node communcations. They can use a common set of commands similar to SMBs, but these commands are determined by the applications themselves.
NetBIOS applications range from the simple Chat-like applets to mainframe gateways and multi-user databases. Any application that needs to communicate with another can use the NetBIOS APIs to do so. Lotus' Notes server for Windows is a NetBIOS application, for example. Also, Microsoft Mail for Windows NT can support NetBIOS. This allows one NT mail client to notify another client that new mail has been sent, using a NetBIOS message. The normal method requires that the recipient workstation check the inbox on a fileserver's shared drive for any unread messages.
NetBIOS applications and the redirector component of Windows for Workgroups all communicate with other machines through the use of the NetBIOS API.
A little history of NetBIOS is perhaps in order here. Several years ago, IBM developed NetBIOS with the goal of developing a network protocol that would work on small networks of PCs. The keyword in that sentence is "small." At the time, the practical limit for an Ethernet segment was 30 nodes, while IBM's own vaunted and un-delivered Token Ring was limited to 255 nodes. There was no need to build in capabilities for moving data between multiple network segments, since nobody was doing it, and the use of gateways to link networks was assumed.
Thus, the design goal was to build a very small and fast protocol. The protocol would provide APIs for the development of network-specific applications that could communicate on a machine-to-machine, or application-to-application basis. Also, the network naming system would allow for human-assigned names of devices, like "MyServer," which is easier to remember and work with than a complex numbering scheme such as TCP/IP. Unfortunately, this design breaks down very quickly in networks of minor complexity, and is completely non-scalable.
NetBIOS was (and continues to be) a broadcast-intensive protocol. Since the assumption was that there were only a few nodes on the network, and that devices would be appearing and disappearing at random (as PCs are apt to do), then it was best to be able to locate a device with a broadcast rather than with any sort of centralized registry. Unfortunately, broadcast packets don't work in today's router-based networks, since the routers don't pass packets that aren't specifically destined for another network node. And since the NetBIOS naming structure is non-hierarchial, devices can't specify remote network segments. Thus, the only way to make NetBIOS work in large networks is to bridge the various segments into a large virtual network. Unfortunately, NetBIOS' reliance on broadcasting limits its use to relatively small networks, so large bridged networks don't work very well either.
NetBIOS uses machine and application names to identify nodes and services available on the network, and for all exchanges of information between them. When Windows for Workgroups starts up, it broadcasts its assigned workstation name, and if no other node challenges the name (or claims to be using it already), it keeps the name for itself. It does not necessarily register the name anywhere, but instead each node is responsible for maintaining its own name tables. If a subsequent node comes on the net and claims the same name, it is the responsibility of the first node to challenge the new one.
Likewise, when a node needs to communicate with another node, it uses broadcasting to find the remote system. The remote system is responsible for responding to the broadcast with a directed reply. Once nodes have identified each other, they can communicate with directed messages.
If you have a NetBIOS application and you wish to communicate with another system or user who is also running that application, then your client will issue a broadcast for the application's NetBIOS name. If the node you are trying to communicate with does not receive the broadcast, then he will not respond, and your client should timeout gracefully. Once your application has located its partner, they will communicate directly.
Fortunately, the NetBIOS APIs can be used with any low-level transport protocol – such as TCP/IP. Unlike NetBIOS, TCP/IP is completely routable. Indeed, it is predominantly a point-to-point protocol that avoids broadcasting whenever possible. Thus, using TCP/IP as a way to move NetBIOS-based data is an attractive alternative to the flat and non-routable NetBEUI protocol that is the default in Windows for Workgroups.
Since NetBIOS uses names for addressing purposes while TCP/IP uses numbers, there must be some way to map the two so that both of them see what they expect. In order for NetBIOS-based applications to run over TCP/IP networks, the NetBIOS application must see names, and the IP protocol must see numbers, yet neither can see the other. A layer between the two must map NetBIOS names to IP addresses, and convert IP addresses back to NetBIOS names. This layer is known as NetBIOS-over-TCP/IP.
TCP/IP standards are defined by Requests for Comment, or RFCs. Anyone may submit an RFC for consideration as a standard (even you). Two such RFCs are 1001 and 1002, which define a standard method for running NetBIOS over TCP/IP. RFC 1001 defines a general overview, while RFC 1002 defines the details.
There are three types of NetBIOS nodes defined in these two RFCs. A b-node (broadcast node) is one that uses broadcasting to query nodes on the network for the owner of a NetBIOS name. A p-node (point-to-point node) uses directed calls to communicate with a known nameserver (not to be confused with DNS) for the IP address of a NetBIOS machine name. An m-node is a mixed node, one that uses broadcasted queries to find nodes, and failing that, queries a p-node nameserver for the address. Another type currently under review is an h-node, which reverses the m-node standard so that a directed query is executed first, and failing that, a broadcast is attempted. Remember that the node types apply only when a node is attempting to match an IP address to a NetBIOS node name. Once the device has discovered the IP address of the machine it's trying to communicate with, it no longer broadcasts information, but sends the IP traffic directly to the node associated with the NetBIOS name.
NBT can use a variety of mechanisms for name resolution. The simplest conceptual and practical method is to simply rely on the default of using broadcasts to locate network resources. This calls for the node to issue TCP/IP broadcasts for every NetBIOS query. Hopefully, the partner system is on your local network, and will see and respond to the broadcast. If you need to be able to configure more exacting name resolution patterns for more complex environments, then you will want to use on of the more powerful options available.
NBT can convert NetBIOS names to IP addresses in several ways. The one described above – broadcasting – hardly seems suitable in anything except the most simple networks. Another potential way to resolve the name is to pre-load the NBT name cache with an IP address. This is accomplished using a text file called LMHOSTS. Another option is to use Windows Internet Name Service (WINS) servers. A WINS server is essentially a p-node as described in RFCs 1001 and 1002, although as an implementation it is proprietary to Microsoft. You can also use your DNS servers as name servers, although this is very limited in functionality.
Assuming you have any of these name resolution options enabled on your Windows for Workgroups PC, the NBT name resolution applies the search in the following order of precedence until a name match is found.
If no match is found, a name-not-found error is returned to NetBIOS.
In essence, a WINS server is a p-node server as defined in RFCs 1001 and 1002. However it is proprietary to Microsoft in implementation. WINS servers have NetBIOS name-to-IP address databases that are built automatically from a variety of sources:
Since the WINS servers are populated by so many forms of network activity, they require almost zero administration, and are extremely reliable at the same time. This makes them the best choice for NBT mappings. A single WINS server that all clients point to can be used to enable browsing across an entire world-wide network, since the reliance on broadcasting has all but been eliminated.
Also, clients that do not have WINS software and (and therefore rely on broadcasting) can take advantage of the WINS servers, since the latter will respond to a broadcast on behalf of a remote system. This means that all NBT nodes now can know about any other node that the WINS server knows about, increasing your network's overall reliability.
As an additional note, you can distribute WINS servers to each of your various network segments. This will provide your local Windows for Workgroups PCs with a browsable interface to your entire network.
To enable name resolution with WINS servers, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.
NameServer1=WINS_IP_address
where WINS_IP_address is the IP address of your WINS server. You can also add a secondary WINS server if you want by defining the "NameServer2=" entry.
If you do not want your WINS servers queried before broadcasts are issued, you can change the search order by adding the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. You MUST have a NameServerX entry defined before you set this flag. Otherwise, you will receive name resolution errors.
NodeTYPE=4
The LMHOSTS database is a raw text file whose format is functionally identical to the TCP/IP HOSTS file. It contains a numerical IP address, a tab character, and a NetBIOS name (and optionally, a comment). LMHOSTS is read by NBT at startup and designated entries are stored in the NBT name cache. This has the absolutely wonderful effect of eliminating all broadcasts destined for nodes or services that are listed in the LMHOSTS file, since the NBT name-to-address entry is already cached.
Do not confuse the LMHOSTS database with the HOSTS database. Although they are similar in use and structure, they serve two entirely separate purposes. The HOSTS file is a database of TCP/IP host names and their corresponding IP addresses, while the LMHOSTS file is strictly for NetBIOS name to IP address mapping. Typically, the LMHOSTS file only shows a few systems. This does not mean that there are only a few nodes on the network, but that there are only a few remote nodes that must be addressed directly. Simply put, the LMHOSTS file allows NBT to take advantage of both the broadcasting and point-to-point architectures without requiring that a dedicated nameserver be on your LAN. Realizing that the "LM" in "LMHOSTS" stands for "LAN Manager" may make the clarification easier.
To enable name resolution with an LMHOSTS file, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.
LMHostFile=C:\MULTINET\LMHOSTS.
You will need to use Notepad or some other text editor to actually create the LMHOSTS text file.
A sample entry in the LMHOSTS file might look like this:
198.93.23.13 TGVFTP # TGV's Public-Access FTP Server
This line simply tells NBT that any NetBIOS queries that are destined for the NetBIOS node TGVFTP are supposed to go to 198.93.23.13. By default, this name would be matched after a broadcast had been issued to the client's local IP broadcast address.
You may also need to define NetBIOS service name mappings. Just as a workstation has a NetBIOS name, so do services such as NetBIOS-based SNA gateways and other workgroup applications. An example of an application entry in the LMHOSTS file might look like the following:
127.1.1.1 SNAGATEWAY # IP address of service SNAGATEWAY
This would tell NBT that the service SNAGATEWAY can be located on the host 127.1.1.1. If you had an SNA terminal emulator that needed to connect to the gateway system using the NetBIOS service name of SNAGATEWAY, then NBT would build an IP packet destined for 127.1.1.1 with a NetBIOS datagram in it.
You need to be careful about the entries you put into your LMHOSTS file. If they are not the correct name or IP address, you will obviously not get the benefit you desired. Some of the most common problems come from not providing the exact NetBIOS host name as the destination system sees it. For example, you cannot simply define the hostname of TGVFTP as TGVSERVER. The server service will not understand the request. Other problems arise when you specify the wrong IP address of the destination system. If NBT has a name-to-address mapping available, it will use it. Providing the wrong address will cause very long delays as the timeouts will have to clear before control is returned to your system.
Since NetBIOS doesn't use port numbers like TCP/IP does, its flat and limited namespace must be capable of supporting a variety of names for each destination system. For example, if you are running an SNA gateway, a licensing server, and a client-server application all on the same system, each of these services must have a unique NetBIOS name that indicates the service itself. The service will not respond if the incoming name does not match the actual service name itself.
Some vendors have gotten fairly creative over the years in assigning these NetBIOS names to their services. Some of them are case-sensitive, while other have gotten into the habit of using hexadecimal characters. While technically this is not a problem in the broadcast-centric nature of NetBIOS LANS of old, it becomes a difficulty when you are working with services running on remote servers.
NetBIOS names can be up to 15 characters in length, with a 16th byte reserved for special end-of-name terminators. In order to identify these names, you must enclose the entry in quote marks, like this:
127.1.1.1 "ScrewySvcName" # Weird NetBIOS service name entry
If you have to use a hex character in the name, then you must preface the character with the tag "\0x", like this:
127.1.1.1 "GATEWAY \0x20" # NetBIOS service name with
# Hex character
The above example would put the hex "20" in the 16th byte of the NetBIOS name.
Whenever a client attempts to log onto a LAN Manager domain, broadcasting is used. Normally, a broadcast message follows the chain of events described above, but where domain controllers are involved, it is sometimes necessary to bypass normal channels. You can tell Windows for Workgroups that it is supposed to attempt domain logins with the hosts that are specified by using the #DOM flag.
In fact, you might want to add #DOM flags for all of the login servers in your domain. Then if the primary domain controller fails, the login request will get sent to the next server listed with a #DOM entry.
To signify that a system is a domain controller, put the #DOM:DOMAIN_NAME flag in the LMHOSTS file as follows, where DOMAIN_NAME is the name of the LAN Manager domain that you wish to login to:
127.1.1.1 MARKETING1 #DOM:MARKETING # Marketing PDC
Note that Windows for Workgroups PCs can NOT login to PathWorks domains at the time of this writing. Although PathWorks is based on LAN Manager, DEC has implemented proprietary mechanisms for logging into PathWorks-based domain controllers. This will not prevent you from connecting to resource on PathWorks servers; it only means that you cannot LOGIN to the domain if you only have PathWorks servers.
Because of TCP/IP's 32-bit numerical node addressing, it is a truly distributed network protocol capable of spanning huge distances and multiple network segments. Unfortunately, these numbers are awfully hard to remember. This is why DNS was invented; it provides a hierachial namespace that maps to IP addresses. Users can reference the host FTP.TGV.COM instead of having to remember that its IP address is 198.93.23.13.
While Microsoft has gone off and developed WINS as a mechanism for building databases that map IP addresses to NetBIOS names, DNS has been around for years, and provides a much more robust mechanism that all applications can use, instead of just NetBIOS apps.
However, the NetBIOS limitations of NBT still apply. The NetBIOS name you are querying for must match the name as registered by the system that owns it. Therefore, it is not possible for you to view the resources on the host FTP.TGV.COM by referencing it with that name. You must refer to it by it's NetBIOS name of TGVFTP.
This severly limits the usefulness of DNS as a NetBIOS name-to-IP address mapping tool. However, it is still very useful for viewing nodes that are in your same TCP/IP domain name. If you had a server called MARKETING1 that was also listed in the DNS under that same name, then you could do away with LMHOSTS and WINS altogether, and just use the existing DNS servers.
To enable name resolution with DNS servers, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.
EnableDNS=1
You will then need to create another section in SYSTEM.INI called [DNS], and under that add the following entry:
DNSServers=DNS_IP_address DNS_IP_address
where DNS_IP_address is the IP address of your DNS server. You can add up to two DNS servers in this field.
Perhaps you are on a small isolated LAN segment yet you often communicate with servers at your corporate headquarters. You would want to take advantage of WINS servers that were on the remote LAN, but you would not want ALL of your name queries to go to that host before broadcasts were attempted locally. Instead, you might want to broadcast first, and if that failed then go check the WINS server. This would give you quick connections to the local services and hosts, while guaranteeing name resolutions (via WINS) for remote systems.
To change the WINS and broadcasting search order, you need to define one of the following entries in the [NBT] section of SYSTEM.INI. You MUST have a NameServerX= entry already defined, or else you will get name resolution errors.
NodeTYPE=1 ; b-node, use broadcasts ONLY NodeTYPE=2 ; p-node, use WINS servers ONLY NodeTYPE=4 ; m-node, use broadcasts, then WINS NodeTYPE=8 ; h-node, use WINS, then broadcasts
One of the few nice things about NetBIOS is that it is simply an API. It does not rely on any specific underlying protocols to connect systems together. For example, Windows for Workgroups' redirector and server (as well as the NetBIOS applications) just talk to the NetBIOS APIs. These APIs can be provided by any protocol. Windows for Workgroups provides NetBEUI and IPX protocols, both of which have NetBIOS APIs available to them. This would allow you to run your Windows for Workgroups file- and printer-sharing (as well as the NetBIOS applications) over IPX if you wanted to. Other vendors provide other protocols with NetBIOS interfaces. Digital's DECnet for example can be used as a transport for Windows for Workgroups' native networking. So can Cisco's Suite 100 for Windows TCP/IP stack. However, all of the systems that wish to communicate with NetBIOS must use the same low-level transport protocol. Otherwise, they would never see each other, and the NetBIOS API would be useless.
In order to provide a consistent interface to these protocols, Windows for Workgroups uses a module called the Transport Driver Interface (TDI). TDI provides a link between NetBIOS and the underlying protocols. Without this interface, the redirector software would need to explicitly understand each of the protocols and their capabilities. Whenever a new protocol was introduced, the redirector would have to be re-written. With TDI, it doesn't have to know anything specifically about any of these protocols. It simply needs to communicate with TDI, which handles the necessary conversion and spoofing needed to make the network software work over the chosen protocol.
The biggest problem with this design is that there must be a virtual protocol for the redirector to communicate with. In the case of LAN Manager derivatives such as Windows for Workgroups, that protocol happens to be NetBIOS, which as we've seen isn't very robust. In order for TCP/IP or IPX to act like NetBIOS, lots of trickery has to occur. You lose a lot of the features that came with the underlying protocols by using a lowest-common-denominator approach such as this.
NetBIOS is extremely limited, but provides a lowest-common-denominator approach to multi-protocol networking. It's use of names for nodes and services makes it easy to use, and its lack of dependancy on any formal hierarchial addressing mechanisms makes it flexible. You can put NetBIOS on top of just about any protocol, from IPX to DECnet to TCP/IP, and it'll work.
However, all sorts of problems arise when you try to map a flat, non-hierarchial namespace onto a distributed, hierarchial address space. There are several options available to the user however, so it is possible to build a name table that meets just about any requirement.
You can use a text file to store static maps (LMHOSTS), or you can setup a Windows NT server to act as a WINS server, or you can rely on your DNS servers already in place. The more complex sites will likely use all of these mechanisms. That's okay!
Whatever methods you choose to employ, remember that NFS doesn't carry any of these burdens, and has much higer levels of portability and availability. You can get NFS servers for AS/400s, HP-3000s, and just about every other platform in the world. And, you can still use your NetBIOS-based applications if you cannot convert them to IP since NBT provides basic NetBIOS name-to-IP address mapping and is not restricted to LAN Manager-centric computing.